Reliable and non-manipulatable processing of data streams in a receiver

ABSTRACT

The invention provides a solution for secure and non-manipulatable processing of a data stream in a receiver, possibly in conjunction with a smartcard. A packet identity and a content type identifier associated with the packet identifier are received in encrypted form and securely processed within the receiver to allow an encrypted payload of the data stream to be processed without the possibility to manipulate the content type identifier in an attempt to intercept the payload after decryption.

CLAIM OF PRIORITY

The present patent application claims the benefit of priority under 35U.S.C. §119 to European Patent Application (EPO) No. 09168907.5, filedAug. 28, 2009, the entire contents of which are incorporated herein byreference.

FIELD OF THE INVENTION

The present invention relates to secure decryption and decoding of datastreams in a receiver, possibly in conjunction with a smartcard.

BACKGROUND

Pay TV applications in a conditional access (CA) system use scrambling(also known as encryption) to secure digital TV broadcast streams.Receivers are used to obtain the relevant decryption keys to descramblethe stream prior to the rendering of the digital TV streams. Suchdecryption key is also known as a control word or CW. In a head-end of adigital TV station a sequence of CWs is associated with one or moreelementary streams such as audio, video, subtitling, teletext and/orapplets. For MPEG2 streams, the elementary streams are identified by aPID (packet identifier). The stream of CWs is usually identifiable by aCW_stream_Id. In the MPEG2 standard, the list of PIDs that make up a TVservice (a program stream in MPEG2 terminology) is contained in a cleartext PMT (program map table). The CA system employs a similar datastructure to map the CW_Stream_ID to a number of PIDs. A decoder in dereceiver processes the PMT and a smartcard of the CA system processesthe information that links the CW_Stream_ID(s) to the relevant PIDs andsets up the receiver to load the relevant keys to descramble theelementary streams.

To prevent unauthorized access to clear text digital TV streams, it isknown to implement the descrambling and the decoding of the digital TVsignals in a secure domain of the receiver, typically in a secure chipor chipset.

Known receivers typically take the following steps in processing a MPEG2stream. MPEG2 packets are received and demodulated. The PID and ascrambling control field are extracted from the MPEG2 header. A CWlookup table in a memory of the receiver is searched for an entry with amatching PID value and associated CW keys are read from the table. Thescrambling control field value is used to select from the associated CWkeys the CW that needs to be loaded in the descrambler. The scrambledpayload of the MPEG2 packet is decrypted in de descrambler using the CW.Information from the clear text MPEG2 PMT is used to determine astream_type of the packet. The stream_type is a content type identifieridentifying the type of content, e.g. audio, video, subtitling, teletextor applet. The stream_type is used to send the packet to the appropriatedecoding module.

For the processing of the MPEG2 stream the receiver typically uses thefollowing inputs: the PID value and the scrambling control field fromthe MPEG2 Packet header and the clear text MPEG2 PMT information ofwhich in particular the PID of the elementary stream and the stream_typeassociated with the PID.

In order to ensure the intended operation of the receiver, all theseinput data need to provide accurate information. As the PMT and theMPEG2 packet header are provided in clear text, they can be manipulatedbefore the processing in the receiver. This enables an attacker tochange a PID value or a stream_type value and e.g. have a video andaudio elementary stream look like a teletext stream. Video streams andaudio streams are typically processed in a secured domain of thereceiver, while, after descrambling, teletext streams are processedoutside the secured domain. Such manipulating of the inputs thus causesthe descrambled video and audio elementary stream to exit the securedomain, enabling unauthorized access to these streams and making theprocessing of the streams unreliable.

SUMMARY OF THE INVENTION

It is an object of the invention to improve secure processing of datastreams.

According to an aspect of the invention a method in a receiver isproposed for processing a data stream. The data stream comprises aheader and an encrypted payload. The header comprises a first packetidentifier. The method comprises the step of decrypting the encryptedpayload to obtain a decrypted payload. The method further comprises thestep of receiving an encrypted second packet identifier and an encryptedfirst content type identifier. The method further comprises the step ofobtaining a second packet identifier from the encrypted second packetidentifier within a secured environment. The method further comprisesthe step of obtaining a first content type identifier associated withthe second packet identifier from the encrypted first content typeidentifier within the secured environment. The method further comprisesthe step of comparing the first packet identifier with the secondidentifier to obtain a first comparison result. The method furthercomprises the step of: if the first comparison result matches a firstpredetermined condition, selecting a first decoding module based on thefirst content type identifier and routing the decrypted payload to thefirst decoding module for decoding the decrypted payload.

According to an aspect of the invention a receiver is proposed forprocessing a data stream. The data stream comprises a header and anencrypted payload. The header comprises a first packet identifier. Thereceiver comprises a descrambler configured to decrypt the encryptedpayload to obtain a decrypted payload. The receiver further comprises afirst input module configured to receive an encrypted second packetidentifier and an encrypted first content type identifier. The receiverfurther comprises a processor, a memory and a router. The processor isconfigured to obtain a second packet identifier from the encryptedsecond packet identifier. The processor is further configured to obtaina first content type identifier associated with the second packetidentifier from the encrypted first content type identifier. Theprocessor is further configured to store the second packet identifierand the first content type identifier in the memory. The processor isfurther configured to compare the first packet identifier with thesecond packet identifier stored in the memory to obtain a firstcomparison result. The processor is further configured to: if the firstcomparison result matches a first predetermined condition, provide thefirst content type identifier to the router. The router is configured toselect a first decoding module based on the first content typeidentifier. The router is further configured to route the decryptedpayload to the first decoding module for decoding the decrypted payload.

The first predetermined condition is e.g. that the first packetidentifier equals the second packet identifier.

Thus, the first content type identifier and the associated second packetidentifier are securely provided to the receiver for processing, i.e.received in encrypted and thereby non-manipulatable form. Moreover, theprocessing of the decrypted payload is dependent on thenon-manipulatable first content type identifier. Advantageously, thisconsiderably complicates changing the content type identifier beforeprocessing in the receiver.

The embodiment of claim 2 advantageously enables the use of entitlementcontrol messages and/or entitlement management messages for the secureddistribution of the first content type identifier.

According to an aspect of the invention a method in a receiver isproposed for processing a data stream. The data stream comprises aheader and an encrypted payload. The header comprises a first packetidentifier. The method comprises the step of decrypting the encryptedpayload to obtain a decrypted payload within a secured environment. Themethod further comprises the step of obtaining a second packetidentifier from a hardcoded memory within the secured environment. Themethod further comprises the step of obtaining a first content typeidentifier associated with the second packet identifier from thehardcoded memory. The method further comprises the step of comparing thefirst packet identifier with the second identifier to obtain a firstcomparison result. The method further comprises the step of: if thefirst comparison result matches a first predetermined condition,selecting a first decoding module based on the first content typeidentifier and routing the decrypted payload to the first decodingmodule for decoding the decrypted payload.

According to an aspect of the invention a receiver is proposed forprocessing a data stream. The data stream comprises a header and anencrypted payload. The header comprises a first packet identifier. Thereceiver comprises a descrambler configured to decrypt the encryptedpayload to obtain a decrypted payload. The receiver further comprises aprocessor and a router. The processor is configured to obtain a secondpacket identifier and a first content type identifier from a hardcodedmemory. The processor is further configured to compare the first packetidentifier with the second packet identifier stored in the hardcodedmemory to obtain a first comparison result. The processor is furtherconfigured to: if the first comparison result matches a firstpredetermined condition, provide the first content type identifier tothe router. The router is configured to select a first decoding modulebased on the first content type identifier. The router is furtherconfigured to rout the decrypted payload to the first decoding modulefor decoding the decrypted payload.

The first predetermined condition is e.g. that the first packetidentifier equals the second packet identifier.

Thus, the first content type identifier and the associated second packetidentifier are securely provided to the receiver for processing, i.e.obtained from a hardcoded memory and thereby non-manipulatable form.Moreover, the processing of the decrypted payload is dependent on thenon-manipulatable first content type identifier. This advantageouslymakes it impossible to change the content type identifier beforeprocessing in the receiver.

The embodiment of claim 4 advantageously enables the hardcoded memorywithin the receiver.

The embodiment of claim 5 advantageously enables the hardcoded memorywithin a smartcard.

The embodiments of claims 6 and 11 advantageously enable restricting theoutput of the decoder to a predefined interface, such as e.g. aHDMI/HDCP-interface, a DVI/HDCP-interface or a DRM protected interface.HDMI, HDCP, DVI and DRM are known abbreviations for High-DefinitionMultimedia Interface, High-Bandwidth Digital Content Protection, DigitalVisual Interface and Digital Rights Management, respectively.

The embodiments of claims 7 and 12 advantageously enable less securedprocessing of decrypted payload for which unauthorized access would beallowable. The second predetermined condition is e.g. that the firstpacket identifier differs from the second packet identifier. The thirdpredetermined condition is e.g. that the first packet identifier equalsthe third packet identifier.

The embodiment of claim 8 advantageously enables secure andnon-manipulatable processing of MPEG2 streams.

The embodiment of claim 13 advantageously prevents tapping of signalswithin the receiver.

According to an aspect of the invention a smartcard is proposed for usein a receiver having one or more of the above described features. Thesmartcard comprises an input module configured to receive an encryptedsecond packet identifier and an encrypted first content type identifierfrom the receiver. The smartcard further comprises a decryptorconfigured to decrypt the encrypted second packet identifier to obtain asecond packet identifier and to decrypt the encrypted first content typeidentifier to obtain a first content type identifier associated with thesecond packet identifier. The smartcard further comprises an outputmodule configured to provide the second packet identifier and the firstcontent type identifier to the receiver.

Thus, a smartcard can advantageously be used for securely obtaining thesecond packet identifier and the first content type identifier andsecurely providing these to the receiver.

According to an aspect of the invention a smartcard is proposed for usein a receiver having one or more of the above described features. Thesmartcard comprises a hardcoded memory. The hardcoded memory comprises asecond packet identifier and a first content type identifier associatedwith the second packet identifier. The smartcard further comprises anoutput module configured to provide the second packet identifier and thefirst content type identifier to the receiver.

Thus, a smartcard can advantageously be used for securely obtaining thesecond packet identifier and the first content type identifier andsecurely providing these to the receiver.

Hereinafter, embodiments of the invention will be described in furtherdetail. It should be appreciated, however, that these embodiments maynot be construed as limiting the scope of protection for the presentinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the invention will be explained in greater detail byreference to exemplary embodiments shown in the drawings, in which:

FIG. 1 a shows a receiver of an exemplary embodiment of the invention;

FIG. 1 b shows a receiver of an exemplary embodiment of the invention;

FIG. 2 a shows a smartcard of an exemplary embodiment of the invention;

FIG. 2 b shows a smartcard of an exemplary embodiment of the invention;

FIG. 3 shows data flows in a receiver and a smartcard of an exemplaryembodiment of the invention;

FIG. 4 a shows a schematic view of steps of a method performed in areceiver of an exemplary embodiment of the invention;

FIG. 4 b shows a schematic view of steps of a method performed in areceiver of an exemplary embodiment of the invention;

FIG. 5 shows a schematic view of steps of a method performed in areceiver of an exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

In a CA system a receiver is a device that receives a data stream fromwhich encrypted data packets are extracted and processed. The datastream can be received as a broadcast stream or originate from a filestored on e.g. a hard disk or DVD disc. The data packets have a headerand an encrypted payload. In the receiver the encrypted payload isdecrypted and decoded to allow playback on an end-user device such as atelevision, pc or audio playback device. Depending on the type ofcontent a particular decoder is used. Types of content are e.g. audio,video, subtitling, teletext and applets. Some types of content are ofparticular interest to hackers because of its premium characteristics,such as video and audio streams.

The data stream is e.g. a MPEG2 stream conforming with the ISO 13818-1standard. The MPEG2 stream typically contains multiple elementarystreams each containing data packets with a header and a payload. Theheader contains a packet identifier (PID). The payload contains contentbelonging to a particular content type. According to the MPEG2 standarda PMT is separately provided to the receiver in clear text, possibly asa data structure within the payload. The PMT contains informationlinking a PID to a content type identifier called stream_type. Comparingthe PID received in the elementary stream with the PID received in thePMT makes it possible to find the stream_type of the payload. The natureof the PMT being clear text makes it manipulatable by hackers.

The present invention provides protection against such manipulations byproviding input data securely to the receiver. The input data includes,amongst others, the content type identifier for an identifiable payload.The input data is used within the receiver where it is protected frommanipulation. Hereto the input data is either encrypted in the broadcaststream or, alternatively, hardcoded in a memory. In case a smartcard isused to obtain the input data, existing techniques can be used tosecurely exchange data between the receiver and the smartcard. Withinthe receiver the payload and input data are preferably processed withina secured chip or secured chipset ensuring that the data signals cannotbe tapped.

In FIG. 1 a a receiver 1 a is shown. Through a first input module 12input data is securely received. The input data as received is encryptedand contains a PID and a stream_type associated with the PID. Processor13 a obtains the PID and stream_type from the input data, e.g. bydecrypting the input data within the receiver 1 a or by having the inputdata decrypted by a smartcard. The obtained PID and stream_type arestored in the memory 14 a for later reference. Multiple PIDs andassociated stream_types can be obtained and stored in the memory 14 a.It is possible to have ranges of PIDs associated with a stream_type toallow a more efficient storage in the memory 14 a.

The receiver 1 a further contains a descrambler 11 for decrypting anencrypted payload of a data packet. The encrypted payload originatese.g. from an MPEG2 elementary stream or from a file. The data packet hasa header containing a PID identifying the payload. After decrypting theencrypted payload, the decrypted payload is to be decoded by aparticular decoder. The decoder is selected by comparing the PID fromthe header of the data packet with the PIDs stored in the memory 14 a.When a match is found, the associated stream_type is read from thememory and a corresponding decoder module 16 is selected. Thestream_type is e.g. indicative of the decoder module 16 to be used orthe stream_type allows a lookup in a table to find the correspondingdecoder module 16. Any other mechanisms to find the decoder module 16with the stream_type may be used. The router 15 routes the decryptedpayload to the selected decoder module 16 where it can be decoded.

In FIG. 1 b an alternative receiver 1 b is shown. In receiver 1 b PIDsand associated stream_types are hardcoded in a memory 14 b and thus neednot be provided through an input module, such as input module 12, inreceiver 1 a. Apart from the secure reception of the input data throughinput module 12, receiver 1 b operates in a similar manner as receiver 1a. In FIG. 1 b the memory 14 b is internal to the receiver 1 b. Thememory 14 b can alternatively be provided in a smartcard accessible bythe receiver 1 b.

In FIG. 2 a a smartcard 2 a is shown that can be used with the receiver1 a as shown in FIG. 1 a to obtain the PID and associated stream_type.Input module 21 receives the encrypted input data containing theencrypted PID and encrypted stream_type from the receiver. Decryptor 22decrypts the input data and the thus obtained decrypted PID andstream_type is provided to the receiver 1 a through output module 23.The interface between the smartcard 2 a and the receiver 1 a is securedusing any known smartcard interface technology.

FIG. 2 b shows an alternative smartcard 2 b that can be used with thereceiver 1 b as shown in FIG. 1 b to obtain the PID and associatedstream_type. The PID and associated stream_type are stored in hardcodedmemory 24 and provided to the receiver 1 b through output module 23.

In FIG. 3 shows in more detail how data is processed in a receiver of anexemplary embodiment of the invention. For simplification purposes, theprocessor 13 a, 13 b is not shown. Data flows are indicated by dashedarrows. References separated by a comma indicate alternatives.References separated by a semicolon indicate multiple data flows betweenelements. Memory 14 a, 14 b is either the hardcoded memory 14 b in whichcase the smartcard 2 a, 2 b is not used, or the memory 14 a in whichcase the smartcard 2 a, 2 b is used to either obtain the PID andassociated stream_type from encrypted input data in smartcard 2 a orobtain the PID and associated stream_type from a hardcoded memory 24 insmartcard 2 b.

In the memory 14 a, 14 b PIDs and associated stream_types are stored.Moreover, PIDs and associated CWs are stored. The CWs are received inthe receiver in a manner known per se, e.g. in entitlement controlmessages (ECMs) wherein two CWs are associated to a PID for a predefinedtimeframe. The two CWs are called odd CW and even CW, which can beselected using a scrambling control field in the header of the datapacket containing the encrypted payload. An example of how the PIDs,stream_types and CWs can be stored is shown in the following table,which can be used as a trusted information lookup table. Any otherstructure for storing these data may be used, as long as thestream_types can be associated with PIDs and the CWs can be associatedwith PIDs.

Trusted Information Lookup Table PID CW_odd CW_even Stream_type 101 CW1CW2 video 201-299 CW3 CW4 1 {ō₁₀₀} ≧ 0 CW1 CW2 audio

The trusted information lookup table contains three rows with data. Inthe first row a PID with value “101”, an odd CW with value “CW1”, aneven CW with value “CW2” and a stream_type with value “video” arestored. Thus CW1 and CW2 are associated with PID 101 and the PID 101 isassociated to the stream_type video. In the second row a range of PIDs201-299 are associated to CW3, CW4 and stream_type 1, wherein the value1 of the stream_type represents e.g. video. In the third row a range ofPIDs {ō₁₀₀}≧0 i.e. {0,100,200, . . . }, is associated to CW1, CW2 andstream_type audio.

Referring to FIG. 3, in the following example a PID and associated CWsare received in an ECM, and a PID and associated stream_type arereceived in an entitlement management message (EMM). The ECM and EMM arereceived by a first input module 12 in a secured domain 30 of receiver 1a and forwarded to smartcard 2 a through a secure interface between thereceiver 1 a and the smartcard 2 a. Encrypted odd CW 112 a and encryptedeven CW 112 b are decrypted in the smartcard 2 a and provided throughthe secure interface as decrypted odd CW 113 a and decrypted even CW 113b, together with PID information from the ECM, to the receiver 1 a wherethey are stored in memory 14 a. Encrypted PID 105 and encryptedstream_type 106 are also decrypted in the smartcard 2 a and provided asdecrypted PID 107 and decrypted stream_type 108 to the receiver 1 awhere they are stored in memory 14 a. When an MPEG2 elementary stream isreceived, data fields are extracted from the header 101 of theelementary stream and the encrypted payload 102 of the elementary is fedinto descrambler 11. Among the data fields extracted from the header arethe PID 103 identifying the payload and the scrambling control field 111identifying whether the odd CW or the even CW is to be used fordecrypting the encrypted payload.

The CWs 113 a; 113 b for PID 103 are looked up in the memory 14 a andbased on the value of the scrambling control field 111 switch 10provides either odd CW 113 a or even CW 113 b to the descrambler 11.Descrambler 11 decrypts the encrypted payload 102 using the provided oddCW 113 a or even CW 113 b. After decrypting the payload, the stream_type108 is sent to a router module 15 along with the decrypted payload 104.The router module 15 uses stream_type 108 from the Trusted InformationLookup Table stored in memory 14 a to select the appropriate decoder fordecoding the decrypted payload 104. Contrary to prior art, PID 109 andstream_type 110 information provided in a clear text PMT and receivedthrough second input module 18 are thus not used. If the stream_type isempty (nil), i.e. not available in the memory 14 a, or invalid, therouter can be configured to use the information from the PMT. The secondinput module 18 and the first input module 12 can be one and the same.

The stream_type 108 in the secured domain 30 can contain or haveassociated routing information for decoding modules 16. This enablesthat e.g. transmission of premium content is restricted to securedoutput interfaces 17 such as HDMI and not on unprotected high qualityanalogue interfaces such as SCART and S-video. There are a number ofways to implement the loading and provisioning of trusted stream_types.A CA system usually provides a mechanism to associate PID values with astream of CWs referenced by a CW_Stream_ID. This mechanism allowsseveral elementary streams to share a CW value. The association of aCW_Stream_ID with PID values occurs prior to the transmission of thesequence of CWs for that CW_Stream_ID. The ECMs thus contain at least anencrypted version of the CW_Stream_ID and the CW 112 a, 112 b. The listof PIDs for a CW_Stream_ID provides a good basis for the additionaltrusted stream_type 107. Instead of a single PID value, the CW_Stream_IDassociation then consists of an array of {PID 107, stream_type 108}pairs. After processing the list of CW_Stream_ID associations, thesmartcard 1 a can use a secure information loading protocol to transmitthe trusted stream_type 108 to the secured domain 30 of the receiver 1a.

Alternatively a special data stream is defined containing the trustedstream_type 108 for a number of PID values 107. In order to preventmodifications to the data, this special data stream is encrypted. Thespecial data stream is decrypted in a descrambler in the secured domain30 of the receiver, possibly descrambler 11. The association between PID107 and stream_type 108 is parsed and stored in memory 14 a for use inthe secured domain 30.

Alternatively two separate CW Lookup tables and separate key ladders arecreated to load the CWs. Known key ladder modules can be used for thispurpose. One CW lookup table contains information for streams that needto stay within the secured domain 30 and the other CW lookup tablecovers elementary streams that are allowed to be decoded by decoders 19outside the secured domain 30. A binary stream_type can he used for thispurpose having either the value of 1 or the value of 0. The key laddermodule implements a secure session process to load CWs 113 a, 113 bdirectly into the secured domain 30 of a chip using a simple keyhierarchy that is embedded into a one time programmable memory structureof the chip.

Other alternative methods may be used for the provisioning of the CWsand stream_types to the receiver 1 a.

FIG. 4 a shows the steps of a method performed in a receiver of anexemplary embodiment of the invention, e.g. the receiver shown in FIG. 1a. Preferably the steps are performed in a secured chip 30 of thereceiver 1 a. In step 1001 encrypted payload 102 of an elementary streamsuch as encrypted video payload is decrypted into decrypted video 104.In step 1002 an ECM or EMM is received with an encrypted PID 105 andencrypted stream_type 106. PID 105 is decrypted and stored in memory 14a in step 1003 and stream_type 106 is decrypted and stored in memory 14a in step 1004. The decrypted PID 107 is compared with a PID 103 of thevideo payload in step 1005. Hereto the PID 103 is extracted from theheader of the elementary stream and compared with PIDs stored in thememory 14 a. If a match is found, which is indicated by step 1006, thestream_type 108 associated with the PID 103 (or PID 107, which isidentical in this case) is read from the memory 14 a and used in step1007 to select a video decoding module 16 for decoding the videopayload. In step 1008 the decrypted video payload is routed to the videodecoding module 16.

FIG. 4 b shows the steps of an alternative method performed in areceiver of an exemplary embodiment of the invention, e.g. in thereceiver shown in FIG. 1 b. The method differs from FIG. 1 a in thatinstead of receiving an ECM or EMM to obtain the PID 107 and associatedstream_type 108, the PID 107 and stream_type 109 are hardcoded in amemory, e.g. in hardcoded memory 14 b of receiver 1 b or in hardcodedmemory 24 of smartcard 2 b. In step 1011 the PID 107 is read from thehardcoded memory 14 b or 24 and in step 1012 the stream_type is readfrom the hardcoded memory 14 b or 24.

In FIG. 5 additional optional steps are shown of a method performed in areceiver of an exemplary embodiment of the invention, e.g. the receivershown in FIG. 1 a. In addition to the steps shown in FIG. 4 a, in theexemplary embodiment of FIG. 5 an interface 17 is selected in step 1013to restrict the output of decoder 16 to in step 1014. If the stream_typeis not found in memory 14 a, the receiver 1 a can be configured to routthe decrypted payload 104, which in this case is e.g. teletext payload,based on input data that is insecurely received in the receiver. Theinput data containing a clear text HD 109 and clear text stream_type 110associated with the HD 109 is e.g. received in a PMT. In step 1015 thePMT is received. In step 1016 the PID 109 from the PMT is compared withthe PID 103 of the teletext payload 104. If the PIDs match, which isindicated by step 1017, a teletext decoding module 19 outside thesecured domain 30 of the receiver is selected in step 1018. In step 1019the teletext payload 104 is routed to the teletext decoding unit 19.

The additional optional steps as shown in FIG. 5 can similarly beapplied to the example of FIG. 4 b.

One embodiment of the invention may be implemented as a program productfor use with a computer system. The program(s) of the program productdefine functions of the embodiments (including the methods describedherein) and an be contained on a variety of computer-readable storagemedia. Illustrative computer-readable storage media include, but are notlimited to: (i) non-writable storage media (e.g., read-only memorydevices within a computer such as CD-ROM disks readable by a CD-ROMdrive, flash memory, ROM chips or any type of solid-state non-volatilesemiconductor memory) on which information is permanently stored; and(ii) writable storage media (e.g., floppy disks within a diskette driveor hard-disk drive or any type of solid-state random-accesssemiconductor memory) on which alterable information is stored.

1-21. (canceled)
 22. A method in a receiver for processing a datastream, the method comprising: receiving the data stream including apayload and a first packet identifier associated with the payload;receiving a second packet identifier and a first content type identifierassociated with the second packet identifier; comparing the first packetidentifier with the second packet identifier to obtain a firstcomparison result; and in response to the first comparison result,selecting a first decoding module from a plurality of decoding modulesbased on the first content type identifier to decode the payload. 23.The method according to claim 22, comprising: comparing the firstcomparison result with a first condition; and in response to determiningthat the first comparison result matches the first condition, executingthe selection of the first decoding module from the plurality ofdecoding modules.
 24. The method according to claim 22, comprising:receiving a third packet identifier and a second content type identifierassociated with the third packet identifier; in response to determiningthat the first comparison result matches a second condition, comparingthe first packet identifier with the third packet identifier to obtain asecond comparison result for selection of a second decoding module fromthe plurality of decoding modules.
 25. The method according to claim 24,comprising: in response to determining that the second comparison resultmatches a third condition, selecting the second decoding module from theplurality of decoding modules based on the second content typeidentifier to decode the payload.
 26. The method according to claim 24,wherein receiving a third packet identifier and a second content typeidentifier comprises: receiving a clear text third packet identifier anda clear text second content type identifier associated with the cleartext third packet identifier; and/or. receiving the third packetidentifier and the second content type identifier in a program map tablein a MPEG2 transport stream
 27. The method according to claim 26,wherein receiving the data stream comprises: receiving the data streamcomprising the payload and the header having the first packetidentifier, the payload and the header being part of an elementarystream in a MPEG transport stream.
 28. The method according to claim 22,wherein receiving a second packet identifier and a first content typeidentifier comprises: receiving the second packet identifier and thefirst content type identifier in an encrypted form, from a secureenvironment.
 29. The method according to claim 28, wherein receiving asecond packet identifier and a first content type identifier comprises:receiving the encrypted second packet identifier and the encrypted firstcontent type identifier in an encrypted entitlement message; andtransmitting the encrypted entitlement message to a smartcard, thesecond packet identifier and the first content type identifier beingprovided from the smartcard over a secure connection.
 30. The methodaccording to claim 22, wherein receiving a second packet identifier anda first content type identifier comprises: receiving the second packetidentifier and the first content type identifier from a secureenvironment comprising either one or more of a hardcoded memory of thereceiver and a smartcard.
 31. The method according to claim 22,comprising: selecting an interface from a plurality of interfaces basedon the first content type identifier; and restricting an output of thefirst decoding module to the selected interface.
 32. A receiver forprocessing a data stream, comprising: a processor configured to: receivethe data stream including a payload and a first packet identifierassociated with the payload, receive a second packet identifier and afirst content type identifier associated with the second packetidentifier, and compare the first packet identifier with the secondpacket identifier to obtain a first comparison result; and a routerconfigured to: in response to the first comparison result, select afirst decoding module from a plurality of decoding modules based on thefirst content type identifier; and route the payload to the firstdecoding module to decode the payload.
 33. The receiver according toclaim 32, wherein the processor is configured to: compare the firstcomparison result with a first condition; and in response to determiningthat the first comparison result matches the first condition, executingthe selection of the first decoding module.
 34. The receiver accordingto claim 32, wherein the processor is configured to: receive a thirdpacket identifier and a second content type identifier associated withthe third packet identifier; and in response to determining that thefirst comparison result matches a second condition, comparing the firstpacket identifier with the third packet identifier to obtain a secondcomparison result for selection of a second decoding module from theplurality of decoding modules.
 35. The receiver according to claim 34,wherein the processor is configured to: determine that the secondcomparison result matches a third condition to select the seconddecoding module from the plurality of decoding modules based on thesecond content type identifier to decode the payload.
 36. The receiveraccording to claim 34, wherein the processor is configured to: receive aclear text third packet identifier and a clear text second content typeidentifier associated with the clear text third packet identifier;and/or receive the third packet identifier and the second content typeidentifier in a program map table in a MPEG2 transport stream
 37. Thereceiver according to claim 32, wherein the receiver receives the datastream comprising the payload and the header having the first packetidentifier, the payload and the header being part of an elementarystream in a MPEG transport stream.
 38. The receiver according to claim34, wherein either one or more of the first decoding module and thesecond decoding module comprises a video decoder, an audio decoder in asecured chipset of the receiver, a teletext decoder, a subtitlingdecoder and/or a software applet that is external to the securedchipset.
 39. The receiver according to claim 32, wherein the processoris configured to: receive the second packet identifier and the firstcontent type identifier in an encrypted form, in an encryptedentitlement message; and transmitting the encrypted entitlement messageto a smartcard, the second packet identifier and the first content typeidentifier being provided from the smartcard over a secure connection.40. The receiver according to claim 32, wherein the processor isconfigured to: receive the second packet identifier and the firstcontent type identifier from a secure environment comprising either oneor more of a hardcoded memory of the receiver and a smartcard.
 41. Thereceiver according to claim 32, wherein the processor is configured to:select an interface from a plurality of interfaces based on the firstcontent type identifier; and restrict an output of the first decodingmodule to the selected interface.
 42. A computer readable storage mediumstoring one or more programs, the one or more programs comprisinginstructions, which when executed by a receiver with a computerprocessor, cause the receiver with the computer processor to perform amethod comprising: receiving the data stream including a payload and afirst packet identifier associated with the payload; receiving a secondpacket identifier and a first content type identifier associated withthe second packet identifier; comparing the first packet identifier withthe second packet identifier to obtain a first comparison result; and inresponse to the first comparison result, selecting a first decodingmodule from a plurality of decoding modules based on the first contenttype identifier to decode the payload.